389 vn/174 vn/174.a
1c1
< From jsq@cs.utexas.edu  Wed Oct  3 11:08:06 1990
---
> From std-unix-request@uunet.uu.net  Wed Oct  3 11:21:46 1990
3,4c3,4
< 	id AA14297; Wed, 3 Oct 90 11:08:06 -0400
< Posted-Date: 3 Oct 90 15:46:12 GMT
---
> 	id AA18463; Wed, 3 Oct 90 11:21:46 -0400
> Posted-Date: 3 Oct 90 14:58:36 GMT
6c6
< From: jason@cnd.hp.com (Jason Zions)
---
> From: jsh@usenix.org (Jeffrey S. Haemer)
8,14c8,10
< Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
< Message-Id: <13142@cs.utexas.edu>
< Sender: jsq@cs.utexas.edu
< Organization: Hewlett Packard, Information Networks Group
< Subject-References: <13132@cs.utexas.edu> <13135@cs.utexas.edu>
< X-Submissions: std-unix@uunet.uu.net
< Date: 3 Oct 90 15:46:12 GMT
---
> Subject: Standards Update, X3J16: C++
> Message-Id: <571@usenix.ORG>
> Sender: jsq@usenix.ORG
15a12,14
> Organization: USENIX Standards Watchdog Committee
> X-Submissions: std-unix@uunet.uu.net
> Date: 3 Oct 90 14:58:36 GMT
18c17
< Submitted-by: jason@cnd.hp.com (Jason Zions)
---
> Submitted-by: jsh@usenix.org (Jeffrey S. Haemer)
20c19
< Dominic Dunlop says:
---
>            An Update on UNIX1-Related Standards Activities
22,28c21
< > I dare say that, as more types of object appear in filename space (and
< > I, for one, should like to see them do so), the question of determining
< > uniqueness will become knottier.  Suppose, for example, that one used
< > filenames as handles for virtual circuits across a wide-area network.
< > Conceivably, the number of such circuits could be sufficiently large
< > that it will become difficult o shoe-horn a unique identifier into the
< > existing stat structure fields.  A problem for the future?
---
>                            October 3, 1990
30,40c23
< Actually, a problem for today. P1003.8 has to cope with the fact that a
< local file for major 0, minor 0x010100, inode 1234 is *different* from a
< file on some remote machine with the same (major,minor,inode) triplet. But
< adding a new field or fields to the stat structure isn't gonna work;
< expanding that structure will cause many implementations to shatter (i.e.
< break spectacularly). Just cobbling up a major number for some random
< remotely-mounted filesystem is unsatisfactory, unless the cobble is
< persistant over umount/mount operations. (An application starts to run;
< opens file1 on remsys, gets (maj,min,ino). Network goes down, comes up;
< system remounts remsys. App opens file2 on remsys. That major number had
< better be the same for remsys!)
---
>                  USENIX Standards Watchdog Committee
42,48c25
< What's needed is a simple routine which can be called to determine if two
< handles point to the same object. It would be nice if there was a routine
< which took as arguments a file handle and a path name and returned true iff
< the path referred to the same file. This routine would be guaranteed by the
< implementor to work for any file-system resident object provided for; e.g.
< an SVR4 implementation would have to be able to tell if a file opened via
< RFS referred to the same underlying file as one opened under NFS.
---
>           Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
50,53c27
< I don't know if that's sufficient, though; application programmers may be
< using the stat info for other purposes, and a remote_addr field might be a
< good idea. Once P1003.12 decides on a representation for an arbitrary
< network address, which might be considerably larger than an IP address.
---
> X3J16: C++
55c29,336
< Jason Zions
---
> Mike Vilot <mjv@objects.mv.com> reports on the July meeting in
> Seattle, Washington:
> 
> Standard C++?
> 
> The C++ programming language has been gaining popularity at a
> remarkable rate (an informal estimate is that the C++ population
> doubles every nine months).  One reaction to the growing popularity
> has been a call to stabilize the language's definition, and achieve
> some consistency across implementations.  C++ is popular enough that
> larger corporations are considering adopting it as an officially
> endorsed development language -- but some cannot make such a move
> unless the language is defined by a standard.
> 
> For these and other reasons, the ANSI secretariat agreed to establish
> the X3J16 committee to formulate a standard for C++.  Dmitry Lenkov,
> of HP, made the official proposal, and serves as chairman of the
> committee.  To date, X3J16 has met three times: an organizational
> meeting last December, the first technical meeting in March to get
> organized, and a meeting in July to really get started.
> 
> The December meeting, in Washington D.C., was purely administrative:
> over 50 attendees received lectures and tons of paper on X3 rules and
> procedures.  The highlight of the day was an invited presentation by
> Bjarne Stroustrup on ``the spirit of C++.'' The transcript is
> available as committee document X3J16/90-0022 or from Greg Comeau at
> Comeau Computing, 91-34 120th Street, Richmond Hill, NY 11418, (718)
> 849-2355.
> 
> March meeting
> 
> AT&T hosted the meeting in New Jersey.  Most of the week was spent on
> administrative matters, while the group got organized and accustomed
> to The Bureaucratic Way.  Since most of the members are engineers, the
> highlight of the week was the evening technical sessions on
> implementing exception handling for C++.  (The week was sort of a
> 
> __________
> 
>  1. UNIXTM is a Registered Trademark of UNIX System Laboratories in
>     the United States and other countries.
> 
> October 3, 1990 Standards Update                            X3J16: C++
> 
> 
> 				- 2 -
> 
> mini-Usenix conference, as most members had gone without a substantial
> C++ gathering since the October '88, Denver conference.)
> 
> The week's major activities were discussing and preparing a goals
> document, describing the committee's activities and priorities.
> 
> Goals
> 
> Here is a brief outline of the goals document, which is available as
> X3J16/90-0023:
> 
>   1.  Base documents: C++ Reference Manual, ANSI C (ANS X3.159-1989),
>       ISO C when available.
> 
>   2.  Standardize syntax and semantics of the language as a token
>       sequence without the presence of preprocessing directives.
> 
>   3.  Define and standardize a minimum set of C++ libraries, their
>       contents, and interfaces.
> 
>   4.  Standardize elements of a C++ environment.
> 
>   5.  Consider proposed major changes: parameterized types and
>       exceptions.
> 
>   6.  Ensure that the standard is suitable for the international
>       community.
> 
>   7.  Ensure a very high level of compatibility with ANSI C.
> 
>   8.  Establish coordinating liaisons with X3J11 (ANSI C) and
>       Numerical C Extensions Group.
> 
>   9.  Produce two deliverables: draft proposed standard and rationale.
> 
>  10.  Priorities:
> 
>          - clear & unambiguous
> 
>          - C++ reference manual
> 
>          - other base documents
> 
>          - consistency
> 
>          - user/implementer experience
> 
>          - portability, efficiency, expressiveness
> 
>          - ease of implementation (including translation to C)
> 
> October 3, 1990 Standards Update                            X3J16: C++
> 
> 
> 				- 3 -
> 
> There was some confusion over the multiple base documents.  Most
> members had seen the AT&TT C++ version 2.0 reference manual, but in
> preparation for standardization, the language and its reference manual
> had suffered a number of subsequent, small changes.  AT&T made the 2.1
> reference manual available to X3J16; it was essentially the text of
> the book The Annotated C++ Reference Manual by Margaret Ellis and
> Bjarne Stroustrup published by Addison-Wesley (minus the annotations).
> 
> My naive suggestion to remove the ANSI C standard as a base document
> in favor of a single base provoked the most intense and emotional
> discussion of the week.  At stake was compatibility between C++ and C.
> 
> While most members of X3J16 feel that the existence of a separate
> committee implies the standardization of a new language, some former
> members of X3J11, which just finished the C standard, want to
> eliminate any and all incompatibilities with C.  (There was even a
> threat to sabotage the C++ standard in balloting if they are not
> removed.)
> 
> This issue is obviously important and has two sides.  Make your
> preferences known to the committee.  For detailed reference material,
> both ``C++: As Close as Possible to C -- But No Closer,'' (Bjarne
> Stroustrup and Andy Koenig, The C++ Report, 1(7), 1989) and Chapter 18
> of The Annotated C++ Reference Manual document and explain differences
> and incompatibilities between the languages as they stand today.
> 
> Focusing on a language without preprocessing directives continues the
> de-emphasis of the C preprocessor.  This is particularly favored by
> C++ vendors looking into more powerful development environments.
> [Editor: Admittedly, improper preprocessor use can sink us in deep and
> dirty bath water, but let's make sure to save the baby.  When writing
> portable C, I personally find #ifdefs extremely valuable; I suspect
> they will remain valuable in C++, and I would hate to see the working
> group neglect this valuable porting tool.]
> 
> The libraries effort includes asking what to do about the ANSI-C
> library, and investigating what can be standardized in a more C++-like
> approach.
> 
> The environment work addresses the linking and executing of C++ code
> with non-C++ code (i.e., linkage and program execution models), rather
> than development environment tools.
> 
> There are thousands of suggested ``improvements'' proposed as
> extensions to C++, but there is consensus on two named in the goals
> document: parameterized types and exception handling.  Their proposals
> are detailed, and both have been implemented (in some form) in a few
> C++ implementations.
> 
> The emphasis on international concerns reflects the lessons learned
> from the difficulties of C standardization.  X3J16 has some fences to
> 
> October 3, 1990 Standards Update                            X3J16: C++
> 
> 
> 				- 4 -
> 
> mend, particularly in the international community.  Rather than
> waiting until the last minute to spring a standard on the ISO, the C++
> committee is involving itself with the international community right
> from the start.
> 
> July meeting
> 
> Microsoft hosted the second, Seattle meeting.  Sub-groups focused on
> the key topics listed in the goals statement began work at the March
> meeting, and reported their progress in Seattle.
> 
> International Concerns
>      Steve Carter, of Bellcore, presented the major International
>      Concerns (particularly character sets and formal specification)
>      and asked the other groups to work on these issues.  He also
>      suggested various sites overseas where future X3J16 meetings
>      could help cooperation with international standardization
>      efforts.
> 
> Editorial
>      Jonathan Shopirio, of AT&T, presented the Editorial group's
>      proposal for organizing and formatting the standard.  Jon is also
>      working on an abstract machine model, and a way to define the
>      semantics in the standard precisely and consistently.
> 
> Formal Syntax
>      James Roskind, an independent consultant, presented the work of
>      the Formal Syntax group.  He has developed (and published on the
>      net) a yacc-able grammar for C++, and is concerned about
>      ambiguities in the the language.  Most of the discussion was
>      spent trying to discover whether C++ can (or should) be made
>      LALR(1).
> 
> Core Language
>      Andy Koenig, of AT&T, presented the Core Language group's work.
>      Initially, they identified and classified difficulties in the
>      working document.
> 
> Environment
>      John Vasta, of HP, presented the work of the Environment group.
>      A key issue addressed by this group is the interaction of C++
>      with other programming languages.  Among the important topics are
>      linkage of C++ and non-C++ translation units, especially the
>      construction and destruction of static C++ objects.
> 
> Libraries
>      I presented the Library group's work.  There were many
>      suggestions, from both inside and outside of the committee.
>      (Interested outside suggesters were James Coggins, Keith Gorlen,
>      and Doug Lea, who have each developed large C++ libraries.) A few
>      people noted similarity with topics covered by other standards
> 
> October 3, 1990 Standards Update                            X3J16: C++
> 
> 
> 				- 5 -
> 
>      (notably POSIX).  Initially, the library group will focus on a
>      few commonly-used components.  Parameterized types and exception
>      handling will significantly effect the way we design libraries in
>      C++.
> 
> Language Extensions
>      Bjarne Stroustrup, of AT&T, presented the work of the Extensions
>      group, which was by far the most active.  The technical sessions
>      presented experience with implementation and use of the template
>      facility.
> 
>      The most active and emotional debate of the week was on exception
>      handling, discussing the proposal outlined by Andy Koenig and
>      Bjarne Stroustrup in their paper ``Exception Handling for C++''
>      presented at the Usenix C++ conference in April.  Martin
>      O'Riordan, of Microsoft, and Mike Miller, of Glockenspiel,
>      presented arguments in favor of extending the current proposal
>      (which defines termination semantics for exceptions) to include
>      resumption semantics.  Andy and Bjarne explained their reasons
>      for not including resumption -- the most important was the
>      complexity and cost of implementation.
> 
>      To their credit, the group worked hard to find a proposal that
>      provided both kinds of exceptions with acceptably small
>      time/space overhead.  However, at the end of the week, Bjarne
>      declared the debate deadlocked, and refused to impose his
>      proposal while substantial disagreement remained.  This is
>      another topic where you should make your opinions heard.
> 
> C Compatibility
>      Mike Miller presented the work of the C Compatibility group.  Tom
>      Plum, of Plum-Hall, produced a list of every section of the C++
>      reference manual that was not C.  Much of the group's near-term
>      activity will be devoted to explaining the many items on the
>      list.
> 
> The Seattle meeting produced tangible progress on the language
> standard.  X3J16 voted to accept the proposed document outline and
> format.  They also agreed to incorporate the template proposal (the
> text from Chapter 14 of The Annotated Reference Manual, minus the
> annotations -- it was literally a scissors-and-tape job).  We hope C++
> vendors will regard templates as now officially in the language, and
> provide users an opportunity to work with this feature.
> 
> Next events
> 
> A few substantial issues lie ahead.  The next meeting should see some
> resolution on the exception proposal.  We should see some progress on
> the review of language ambiguities and inconsistencies, and have some
> idea of how difficult it will be to ANSIfy the document.  We should
> also see some specific proposals on library contents.  The most
> 
> October 3, 1990 Standards Update                            X3J16: C++
> 
> 
> 				- 6 -
> 
> substantial will be a simplified version of iostreams by Jerry Schwarz
> (now at Stardent, formerly at AT&T).
> 
> Our target date for delivering a draft standard is the end of 1992.
> X3J16 meets three times per year.  The next three meetings (and their
> hosts) will be:
> 
>    + November 12-26, Cupertino CA (Hewlett Packard)
> 
>    + March 11-15, Nashua NH (Digital)
> 
>    + June 17-21, Lund Sweden (Lund Institute of Technology)
> 
> Membership on an X3 committee is open to any individual or
> organization with expertise and material interest in the topic
> addressed by the committee.  The cost for membership is $250.  Contact
> the chair or vice chair for details.
> 
> Chair: Dmitry Lenkov
> HP California Language Lab
> 19447 Pruneridge Avenue MS 47 LE
> Cupertino, CA  95014
> (408)447-5279
> FAX (408)447-4924
> email dmitry%hpda@hplabs.hp.com
> 
> Vice Chair: William M.  Miller
> Glockenspiel, Ltd
> P.O. Box 366
> Sudbury, MA  01776-0003
> (508)443-5779
> email wmmiller@cup.portal.com
> 
> October 3, 1990 Standards Update                            X3J16: C++
